GuardDutyの検出結果をFirehose経由でDatadogに転送してみた

AWSチームのすずきです。

AWSが提供する脅威検知サービス「GuardDuty」、 その検出結果を サードパーティへのデータ配信をサポートした 「Kinesis Data Firehose」 を利用して 「Datadog Logs」に転送、集約管理を試す機会がありましたので紹介させていただきます。

AWS設定

GuardDuty

「GuardDuty の有効化」のみ実施しました。

Firehose

データ配信先として「Datadog Logs」を設定した 配信ストリームを利用しました。

EventBridge

GuardDuty の 検出結果を Firehose に転送するルールを新規に作成しました。

サービスごとの事前定義パターンを利用し、以下設定を行いました。

• サービスプロバイダ: 「AWS」
• サービス名 : 「GuardDuty」
• イベンドタイプ: 「GuardDuty Findng」
• ターゲット: 「Firehose配信ストリーム」
• ストリーム: 事前にDatadog Logs 転送設定を実施したストリームを指定

GuardDutyサンプル

GuardDuty の検出結果のサンプルを生成します。

Datadog 設定

サンプルログ確認

GuardDuty のログは、EventBridge、Firehose を経由して、5分前後でDatadog 上で確認可能になります。

パイプライン

ログ処理を行うパイプラインを設定します。

GuardDuty用として用意された設定を「Browse Pipeline Library」より選択、複製して利用しました。

2020年8月時点では Firehose経由で転送されたGurdDutyログが処理対象外とならないフィルタ設定が存在します。 GuardDuty用のパイプライン設定の複製時、フィルタ設定を「source:guardduty」→「source:aws」と変更しました。

パイプライン設定後、「GuardDutyサンプル」を再実行します。 5分程度経過した後、パイプラインにより加工されたログが Datadog Logs 上に表示されます。

Facet設定

フィルタ、絞り込み対象として利用するログ項目を指定します。

以下の設定を「Add Facet」で追加しました。

Facet	内容
@account	AWSアカウント番号
@region	AWSリージョン
@detail.severity	GuardDutyの重要度
@detail.service.serviceName	ログ識別用
@evt.name	GuardDuty 結果タイプ
@title	GuardDuty 結果詳細

設定後「GuardDutyサンプル」を再実行、5分待機します。

指定した項目による絞り込みが可能となっている事を確認します。

フィルタ設定

パイプラインのフィルタ設定に「@detail.service.serviceName:guardduty」を追加、 GuardDuty ログ専用のパイプラインとして機能するように設定しました。

ログレベル設定

Category Processor

GuardDuty ログに含まれる「severity」の値は 0～10の範囲で、高い値が重度の問題である事を示す仕様です。

• Amazon GuardDutyの結果

Datadog Logs上でのログレベル、ステータスの識別を可能にするため、 GuardDuty ログ用のパイプラインに「Processor」を追加、GuardDuty 重要度を示す数値を 一般的なSyslog の Severity に変換します。

• Target category attribute: severity_syslog
• Poplate category (GuardDuty Severity値 -> severity_syslog)変換

MATCHING QUERY(GuardDuty Severity)	GuardDuty重要度	severity_syslog
@detail.severity:[7 TO 8.9]	High	Error
@detail.severity:[4 TO 6.9]	Medium	Warning
@detail.severity:[1 TO 3.9]	Low	Notice
@detail.severity:[9 TO 10]	(予約)	Critical
@detail.severity:[0 TO 0.9]	(予約)	Informational
-	-	Emergency
-	-	Alert
-	-	Debug

Status Remapper

Category Processor で 変換した、「severity_syslog」を Datadog Logs のログステータスに反映させる「Processor」設定を追加します。

パイプライン動作確認

以下のGuardDuty用パイプライン設定後、「GuardDutyサンプル」を再実行しました。

• FILTERS
• Category Processor
• Status Remapper

GuardDutyの重要度が Datadog Logsの ステータスに反映、色分け表示が可能になりました。

費用

GuardDutyの検出イベント、1件5KBのログが 月間 1000 ～ 1000000 件 発生する想定で、 Datadog Logs と Firehose の料金を試算してみました。

ログ件数(月間)	Datadog(件数)	Datadog(容量)	Firehose(容量)	費用合計(Datadog+AWS)
1000	$0.003	$0.001	$0.000	$0.003
10000	$0.026	$0.005	$0.002	$0.032
100000	$0.255	$0.050	$0.018	$0.323
1000000	$2.550	$0.500	$0.180	$3.230

GuardDutyの検出イベントログのDatadog転送、多くの環境では低コストでの利用が可能と思われます。

まとめ

GuardDuty と Datadog Logs の連携、これまでも Lambda関数を利用する事で実現可能でしたが、 Firehoseのアップデートにより、コード実装なく利用することが可能になりました。

Datadog を利用する事で、柔軟なアラート設定や Slack などチャット通知なども実現可能です。 GuardDuty のより効率的な利用を実現するツール Datadog Log、その連携手段としてFirehose をぜひお試しください。

参考